-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fw 956 refactor on changes #28187
Fw 956 refactor on changes #28187
Conversation
You can preview 9cff51c at https://pr28187-9cff51c.ngbuilds.io/. |
9cff51c
to
c39d3c7
Compare
You can preview c39d3c7 at https://pr28187-c39d3c7.ngbuilds.io/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General approach looks good, but we need the tests turned on to verify
packages/upgrade/test/static/integration/downgrade_module_spec.ts
Outdated
Show resolved
Hide resolved
packages/upgrade/test/static/integration/downgrade_component_spec.ts
Outdated
Show resolved
Hide resolved
@@ -81,13 +81,13 @@ | |||
"name": "NO_PARENT_INJECTOR" | |||
}, | |||
{ | |||
"name": "NodeInjectorFactory" | |||
"name": "NgOnChangesFeature" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems odd that we are bringing NgOnChangesFeature
into hello_world
. Why would that be the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suspect this is a bug with the how the compiler is identifying the presence of the feature and adding it. I think we can fix this in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer we get to the bottom of extra inclusion, unless it is blocking something. Fix up PR later tend to not happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah! 🎉
ngDevMode && assertDataInRange(lView, index); | ||
const def = tView.data[index] as DirectiveDef<any>; | ||
const setInput = def.setInput; | ||
if (setInput) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intermediate assignment seems unnecessary, removing it avoids the !
:
if (def.setInput) {
def.setInput(instance, value, publicName, privateName);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an optimization to prevent it from being looked up twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benlesh it would be, if the call didn't rely on this
being the DirectiveDef
(or we should use setInput.call(def, …)
. We are currently reading it twice already because of that.
function ngOnChangesSetInput<T>( | ||
this: DirectiveDef<T>, instance: T, value: any, publicName: string, privateName: string): void { | ||
const simpleChangesStore = getSimpleChangesStore(instance) || | ||
setSimpleChangesStore(instance, {previous: null, current: null}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems as if we can assign EMPTY_OBJ
into previous
here immediately, such that it is guaranteed to be present (the NgSimpleChangesStore.previous
property may loose null
from its type and the assignment of local var previous
below can be inlined into the assignment of previousChange
)
You can preview 8c07bd4 at https://pr28187-8c07bd4.ngbuilds.io/. |
You can preview 00bc640 at https://pr28187-00bc640.ngbuilds.io/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Note: missing reviews. |
@@ -34,20 +34,14 @@ import {Directive, EmbeddedViewRef, Input, OnChanges, SimpleChange, SimpleChange | |||
*/ | |||
@Directive({selector: '[ngTemplateOutlet]'}) | |||
export class NgTemplateOutlet implements OnChanges { | |||
private _viewRef: EmbeddedViewRef<any>|null = null; | |||
// TODO(issue/24571): remove '!'. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file appears to have been accidentally reverted when I reverted the other onChanges changes.
(changes changes changes)
99787db
to
907b92f
Compare
- Wraps the NgOnChangesFeature in a factory such that no side effects occur in the module root - Adds comments to ngInherit property on feature definition interface to help guide others not to make the same mistake - Updates compiler to generate the feature properly after the change to it being a factory - Updates appropriate tests
Adding one more bit of work to this to resolve FW-965, which is that the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* | ||
* NOTE: DO NOT SET IN ROOT OF MODULE! Doing so will result in tree-shakers/bundlers | ||
* identifying the change as a side effect, and the feature will be included in | ||
* every bundle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for including this 👍
merge assistance: no longer need public-API approval because the public API changes were reverted (no longer in this PR). Should be good with approval from @mhevery and i. |
- Wraps the NgOnChangesFeature in a factory such that no side effects occur in the module root - Adds comments to ngInherit property on feature definition interface to help guide others not to make the same mistake - Updates compiler to generate the feature properly after the change to it being a factory - Updates appropriate tests PR Close #28187
- adds fixmeIvy annotation to tests that should remain updated so we can resolve those issues in the subsequent commits PR Close angular#28187
…ar#28187) - Wraps the NgOnChangesFeature in a factory such that no side effects occur in the module root - Adds comments to ngInherit property on feature definition interface to help guide others not to make the same mistake - Updates compiler to generate the feature properly after the change to it being a factory - Updates appropriate tests PR Close angular#28187
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This change inverts the control over who is setting up onChanges to fire from the parent template to the component/directive definition itself. The idea is that the new
NgOnChangesFeature
will add asetInput
function to the directive definition that is to be called when setting an input from a parent template. ThatsetInput
function will be composed to update aSimpleChanges
object that is now stored at a known private property on the component instance.Reverts most of the changes from the #27965 PR that moved control of onChanges into the parent template's instructions.